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PREFACE 


This Executive Summary provides a synopsis of the final report prepared 
under MSC/TRW Task ASPO-92, "Apollo Spacecraft Operational Data Management 
System Analysis." During the course of this three-month study, topical 
working papers were presented and discussed at bi-weekly MSC/TRW review 
meetings. The study final report is based on restructured and clarified 
versions of these papers. Since this Summary and the Final Report have 
differing orders of content, the Summary text provides references to that 
Report to facilitate quests for greater detail. 
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1 . INTRODUCTION 


The purpose of Task ASPO-92 was to study Apollo, Skylab and several 
other data management systems to learn what techniques can be applied to 
the management of operational data for future manned spacecraft programs. 
Operational data is defined as: 

"Data which describe spacecraft and spacecraft 
subsystems performance capabilities and limita- 
tions, and which are required to accomplish mis- 
sion planning, analysis, and/or real time support." 

The study was performed by: 1) analyzing present data management systems, 

2) developing requirements for future operational data management systems, 

3) evaluating automated data management techniques, and 4) preparing a plan 
for data management applicable to future space programs. As this study 
progressed, it became increasingly evident that cost-effective management 
of spacecraft operational data must include consideration of other techni- 
cal data such as test results, configuration control, and reliability. The 
interplay between data sources, data users, and program time phasing pro- 
duces a situation where operational data can be made largely a by-product 
of other data-producing activities of the program. Furthermore, the pro- 
cesses which produce the purely technical data are also potential generators 
of management data required for program visibility and decision-making. It 
was concluded that a cost-effective approach to operational data lay in the 
direction of an integrated data base containing at least the technical and 
management information of the program. 

This conclusion is reflected in the plan recommended for future programs, 
a plan based on the potential utility to MSC of a center-wide Information 
Management System (IMS) serving all Center Groups. The IMS would be user 
oriented, have several coordinated elements, and function as a service. The 
user determines how he will apply the IMS to his needs and what data he will 
manage. One element of the system would promote commonality, set standards, 
establish procedures, encourage compatibility among users, and provide user 
training in the IMS application. Other elements would provide computer-based 
data processing functions and those functions not feasible for automation. 
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2. ANALYSIS OF PRESENT DATA MANAGEMENT SYSTEMS 


2.1 APOLLO AND SKYLAB 

2.1.1 System Description . The Apollo Operational Data Management System 
(DMS) began in 1965, when the need for a single authoritative source for 
spacecraft operational data was recognized by the Apollo Spacecraft Program 
Office and the Mission Planning and Analysis Division. Since then the 
system has evolved to meet the needs of the Apollo Program as it progressed 
through the mission planning and operational phases. The present Apollo 
system produces the Spacecraft Operational Data Book (SODB) which is a 
seven-volume Class I document, and also provides additional data as re- 
quired by the many individual data users. While this system uses a com- 
puter to perform certain calculations, it is considered to be a manual 
system because all major activities are performed manually, and data are 
handled, formatted, and published manually. Skylab activities began two 
years later than Apollo with an Operational DMS similar to that of 
Apollo. Skylab operational data are published in a five-volume Operational 
Data Book (ODB). A simplified flow diagram and description of the Apollo 
and Skylab Operational Data Management Systems are presented in Figure 1. 
Detailed flow diagrams and descriptions are contained in Appendix A of the 
Final Report, and the contents of both the SODB and the ODB are described 
in Appendix D. 

While the Apollo and Skylab DMS's are similar, two factors necessi- 
tated study of both systems, viz.; 

1) The Skylab system was structured to avoid some early Apollo 
system problems. An assessment of the effectiveness of 
these changes is required. 

2) The Skylab system involves two NASA field centers (while the 
Apollo system is captive to MSC) and is more representative of the 
future situation with multi -center data management functions. 

2.1.2 Problems Experienced . The management objective of the Apollo 

and Skylab spacecraft operational data systems has been simple: to obtain 

and provide accurate spacecraft data in a timely fashion to satisfy the 
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SODB-ODB BASIC DATA FLOW 



OPERATIONAL DATA FLOW DESCRIPTION 

The basic functional flow as shown above is representative of both the 
Apollo and Sky lab Operational Data Management Systems. The basic functions 
are as follows: 

1. In fulfillment of MSC data requirements, data are submitted by 
the responsible contractor (or NASA) to MSC for incorporation 
in the SODB or ODB. 

2. Data submitted by NASA or contractors are evaluated for incorpor- 
ation in the SODB or ODB. 

3. If the data are approved by the contractor and/or Program Office, 
the data are given to the NASA SSM for evaluation and validation. 

4. If the data are not approved for SODB-ODB incorporation by the 
contractor and/or Program Office, an attempt is made to resolve 
discrepancies and delete inappropriate data; without resolution, 
the data are published as a NASA Data Source (without contractor 
concurrence) . 

5. After data approval by the SSM, MSC approves, formats, publishes 
and distributes the data to the designated standard and special 
users. 

6. As the user identifies more data requirements to satisfy his 
planning needs, he submits data requirements to the Program 
Office. The Program Office evaluates the requirements versus 
the need to obtain these additional data at no additional costs 
or added costs (as the case may be). 

7. If these data requirements are approved, the data requirements 
are imposed on the appropriate data supplier who will prepare 
data submittals and forward them (as described in 1. above) to 
MSC. 


Figure 1. SODB-ODB Basic Data Flow 
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requirements of the large data user community. However, implementation to 
accomplish this objective in the real world has been more complex. Some 
of this complexity is caused by the need to define data requirements con- 
current with design of the techniques for use of the data, e.g., software 
modeling, and the need to use data prior to development of the spacecraft 
systems which the data must characterize. During the early planning phase 
of Apollo, this resulted in vague definitions of requirements by the users 
and a reluctance to estimate data values by the data suppliers. When data 
was obtained, the MSC subsystem managers did not effectively respond in 
their validation role. In general, many of the participants in the data 
management system were uncertain about the purpose and authority of the 
data and its relationship to other data in the program. The presence of 
redundant data in the many technical documents of the program served to 
nurture this uncertainty. As time passed, program problems occurred which 
were attributable to data deficiencies; therefore, management involvement 
increased. Simultaneously, the coordinating efforts of the data management 
group of ASPO were causing an awareness of the data management objectives to 
permeate throughout MSC. By the time the operational phase of Apollo was 
reached, these occurrences had coupled with the increased knowledge of both 
data requirements and data values to yield a widely recognized and supported 
spacecraft operational DMS. 

However, at this point the cost was high, for large sets of previously 
unplanned data requirements began to unfold and were imposed on the data 
suppliers (mostly Apollo contractors). This resulted in costly add-ons 
to contracts, with schedules for fulfillment of these requirements, and 
even some of the requirements severely compromised to maintain reasonable 
costs. More harmful instances occurred when the opportunity to acquire 
critical data was missed and the data were subsequently irretrievable. 

At present, schedules for some key data are uncontrolled, resulting in 
the submittal of large masses of data so close to Apollo launch dates as 
to severely compromise the value of the data. 

The growing pains experienced by MSC on Apollo have been alleviated 
somewhat on Skylab. Lessons learned from Apollo caused greater awareness 
of operational data requirements and acceptance of the operational data 
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management concept throughout MSC at earlier stages of program development. 
However, there are problems similar in nature to previous Apollo problems: 

1) there are redundant and conflicting data among documents from which 
operational data are derived; 2) the data validation role, while improved 
over Apollo, leaves much to be desired in terms of response priority; and 
3) there are uncertainties among some of the DMS participants about their 
responsibilities. These problems serve to impede the timely fulfillment 
of data requirements. 

During the course of this study, both users and validators of Apollo 
and Skylab data were surveyed to determine their attitude about the Opera- 
tional DMS and their involvement with the system, and to solicit recommenda- 
tions for improvements applicable to operational data management for future 
spacecraft programs. Surveys were conducted with TRW, MSC, and MSFC per- 
sonnel. The TRW survey was performed first and served as a basis for re- 
finement of the survey technique prior to surveying MSC and MSFC. The 
results of these surveys are presented in Appendix C of the Final Report. 

A summary of survey results, presented in Table 1, serves to substantiate 
the above discussion of Apollo and Skylab Operational Data Management 
problems encountered at MSC. 

The MSFC survey results summarized in Table 1 were based on interviews 
with seven data users and seven data validators during a one-day meeting, 
and because of this small sample, may not reflect the general attitude of 
MSFC. However, the results suggest a situation at MSFC which is similar 
to the situation of uncertainty which prevailed at MSC during the early days 
of Apollo. While the MSFC data management personnel present during these 
interviews were attuned to the goals of the operational DMS, the data users 
were uncertain about the purpose, content, and authority of the ODB. In 
reality, they are probably not users, for they appear to circumvent the 
intent of the ODB by fulfilling their data requirements through contact 
with whomever they believe to be a reliable source. The MSFC validators 
appear to take their validation role seriously, but do not appear to use 
the ODB as a reliable source of data. 
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Table 1. Summary of User/Validator Surveys 
Conducted July and August 1971 
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validation appears to be performed con^ ^ Sky lab 
scientiously, even though they did not know * only 
purpose. 



2.1.3 Concl usions . The problems experienced by MSC with Apollo and Skylab 
Spacecraft Operational Data Management Systems led to some significant 
conclusions about those factors which contributed to a successful system, 
and those factors which adversely affected success. 

1) Program office and user management emphasis and conscientious 
data management group activities have resulted in widespread user 
acceptance of the "single authoritative data source concept." 

2) In general, line management emphasis on the validation role is 
insufficient, which adversely affects the timeliness of data. 

3) The complexities of handling and updating large quantities of 
paper serve to inhibit the smooth and timely flow of data. 

4) The definition of data requirements subsequent to the early 
planning stages of a program results in costly contract additions, 
and compromised fulfillment of data requirements. 

Based entirely on the small sample size survey conducted at MSFC, the 
situation appears similar to the situation at MSC four years ago, viz.; 

1) The relationships and purposes of program documentation are 
unknown by those expected to use the documentation. 

2) Except for establishment of an MSFC data management group, high- 
level management emphasis on participation in the Skylab Opera- 
tional Data Management System appears lacking. 

2.1.4 Recommendations for Apollo and Skylab Improvements . While the 
primary orientation of this study is focused on recommendations applicable 
to future manned programs, the study results indicate that some improve- 
ments to the current Apollo and Skylab operational DMS's would be cost- 
effective. The following actions are recommended to facilitate these 
improvements. 

1) The advantages of single authoritative data sources between 
centers, and the need to identify these sources should be dis- 
cussed with MSFC management. 

2) Firm and realistic schedules for submittal of contractor supplied 
data to MSC should continue to be pursued by the Program Offices. 

3) Greater emphasis should be placed on the timely validation and 
supply of data by line management, and alternate validation 
authorities should be designated. 
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4) Requirements should be established for suppliers to submit data 
changes as soon as the data becomes available, and to assess all 
hardware and redline changes, and ground and flight test results 
for operational data impacts. 

5) The roles and responsibilities of all Skylab data management 
participants should be explicitly defined. 

6) The SODB should be printed at one facility only and high priority 
should be given to printing and distribution. 

2.2 DATA MANAGEMENT SYSTEMS OTHER THAN APOLLO AND SKYLAB 

The Titan II and Minuteman (Ballistic Missiles), Cheyenne (Helicopter), 
and Kentucky (State Government) Integrated Data Management Systems were 
studied to determine characteristics which could be applied to enhance 
effective management of data for future manned spacecraft programs. These 
are systems with which TRW has been associated and with which the study 
team is familiar. Descriptions of these systems are provided in Appendix 
B of the Final Report. Significant characteristics of these systems are 
presented in the following paragraphs. 

2.2.1 Titan II and Minuteman . Early integrated planning of technical data 
needs was an important contributing factor to program success, as well as 
to data management system success. Contractually imposed specifications 
called for program-wide functional analyses which were sensitive to the 
definition of specific data requirements. The data then evolved from 

more detailed analysis efforts to fulfill these requirements. It is 
interesting to note that throughout the duration of the program, functional 
analysis data were used effectively as a systems integration tool. 

In Minuteman, the responsibility for both the end item specifications 
and operational performance estimates were consolidated within the same 
personnel groups. Similar consolidation of data validation responsibil i- 
ties has occurred during the management of the Skylab and Apollo operational 
data and is desirable for future programs. 

2.2.2 Cheyenne . An early study of program data requirements by the 
Cheyenne Program Manager resulted in the development of the Integrated 
Technical Data System (ITDS) and is believed to be the primary factor 
leading to widespread acceptance by program personnel. ITDS was organized 
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as an integrated data system for management of all program data. The system 
was considered very effective in assisting the management of the program. 

2.2.3 Kentucky . The Kentucky Data Management System was patterned after 
ITDS and reflects a modularized information management system approach which 
is planned to eventually handle most of the state government's data. It 
is presently used to manage Highway Department, State Finance, Personnel, 
and Executive Office data. The personal involvement of the Governor of 
Kentucky is credited with achieving ready acceptance by the many partici- 
pants. 
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3. REQUIREMENTS FOR FUTURE OPERATIONAL 
DATA MANAGEMENT SYSTEMS 


The requirements necessary to develop an effective future spacecraft 
operational Data Management System (DMS) were based on results of the 
analyses described in Section 2. The complete set of requirements (sub- 
divided to group management policy, system implementation, and operational 
data requirements) is presented in Section 2 of the Final Report. The 
content of this Executive Summary is confined to a discussion of only 
those requirements which deserve to receive high-level management attention. 

The development and subsequent ratification of an operational data 
policy required a long time to evolve on Apollo and was accompanied by 
costly implementation. A key lesson from Apollo is the need for early 
committment by senior management to a specific policy concerning an opera- 
tional DMS. 

It is recommended that management endorse the following requirements 
for future operational DMS's, and that these requirements be reflected in 
policy direction to all participants. 

1) The operational DMS shall be a subset of a total planned Technical 
Data Management System for the program. This requirement would 
assure early planning of the primary data needs of a program, and 
would facilitate four important contributions to cost-effective- 
ness: 

a) It would foster a planned relationship between operational 
data and the many technical functions from which it is derived, 
e.g., specification development and qualification testing. 

This would cause operational data requirements to be coupled 
with the other data requirements related to each function. 

b) It would enhance a clear definition of authoritative program 
data. This would preserve the concept of a single authori- 
tative source for spacecraft operational data which is 
presently acclaimed, but was painfully achieved for Apollo. 
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c) It would, if widely promulgated, provide center-wide visibility 
of key program data. This would serve to inhibit the occurrence 
of special-purpose redundant data which arises from uncertain- 
ties about the content and interrelationships of planned pro- 
gram data. 

d) It would promote explicit definition of DMS roles, with assign- 
ments made in consonance with program need and understood and 
accepted throughout the center. 

2) The program DMS shall be defined prior to contractor participation 
and shall be reflected in all program requests for proposals. 

This requirement would cause all prospective contractors to bid 
against a known data baseline in a competitive manner and would 
result in early familiarity with the required data support 
responsibilities and participant roles. It would also serve to 
inhibit subsequent add-on costs attributed to bidding uncertainties. 

3) The program plans shall enable continual definition, refinement 
and evolution of data requirements throughout the program with 
minimal contractual effect. This requirement would cause plans 
and processes to be developed which would cope with the inherent 
inability to completely define all operational data requirements 
at the beginning. Solutions are expected to require continuing 
interaction between the spacecraft design and development and 
mission and operations planning and thus are a part of the system 
engineering function. 


11 



4. AN INFORMATION SYSTEM FOR A FUTURE SPACECRAFT PROGRAM 


4.1 GENERAL 

The analysis of spacecraft operational data in the Apollo program has 
exposed two significant and unique characteristics, viz; 

1) Operational data can be obtained as a by-product of 
activities conducted for other purposes. 

2) A time paradox occurs between availability and need. 

The first of these characteristics is the basis for the subsequent dis- 
cussion while the second is discussed in Section 6. 

The user of operational data is not normally associated with the source 
of the data. His data requirements are met by activities that are con- 
ducted for purposes other than the production of operational data; hence, 
operational data can be extracted as a by-product from the "data pools" of 
other program activities. In order to alleviate data management problems, 
the information required for the management of operational data should be 
obtained in a similar way. Thus, both operational data and information 
for its management (e.g., status and availability) should be obtained as 
an adjunct output of many different program activities. We recommend that 
the effective solution for operational data management is an integrated 
(and automated) data base for both the technical data and management infor- 
mation of a program. 

Based on the lessons learned from the study of Apollo and other Infor- 
mation Management Systems (IMS), a plan for an IMS for a future spacecraft 
program has been developed and is described in Section 1 of the Final Report. 
The plan is based on the expectation that MSC will provide a user-oriented 
information management service for its operating elements. This service 
will take the form of software and hardware configurations which are suit- 
able for general purpose data storage and retrieval and are compatible with 
integrated data bases. The configuration would be managed by a Center 
Data Management Office. The reasons for a center-wide system are to mini- 
mize the cost of software, to ensure compatibility of systems among users 
and between programs so that data can be readily exchanged, to simplify 
training of users, and to coordinate prioritized assignment of computer 
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terminals. Three rules have been adopted to guide the system design: 

1) use the MSC functional structure, 2) plan on use of existing MSC hard- 
ware and software, and 3) recognize that acceptance of a new information 
management approach will take time to evolve and be accepted. 

4.2 SYSTEM CONCEPT 

The overall system concept is shown in Figure 2. As the figure em- 
phasizes, a key to the operation of the system is the existence of a data 
base containing the common pool of data for the program. The ready access 
to this data by all persons engaged on the program is assured through a 
combination of computer terminals and computer-aided access to hard copy 
files. By its existence, the data base injects a degree of discipline 
into the management of program data that is not possible with fragmented 
systems. 

A second key to smooth operation of the data base, and thereby the 
total IMS, is the existence within the Program Office of several applica- 
tions engineers who are knowledgeable of the operation of the total IMS as 
well as being de facto representatives of MSC development organizations. 
Within the system concept, the applications engineers would be expected to 
integrate requirements for operational data with those for other functions. 
For example, basic proof-of-performance test data requirements specified 
by a subsystem manager would be expanded to include the reporting of out- 
of- limits performance data for operational data needs. The applications 
engineers would also be the principal interface through which information 
would be supplied to the data base. They would develop the file structure 
and indexing procedures for the data base and would provide assistance to 
users who are not familiar with the mechanics of search and retrieval. 

The system depends heavily on automation for its eventual cost- 
effectiveness. The Computation and Analysis Division (CAD) of FOD has been 
studying software which, together with the 1106/1108 computer complex, could 
form the basis for an operational system. This service would be coordi- 
nated by the Center Data Management Office (CDMO) which would integrate 
automation, hard copy, and procedural aspects into a center-wide IMS. 

From then on, the CDMO would maintain configuration control, and provide 
guidance in the use of the IMS to operating elements in the program offices 
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and functional directorates. The IMS would be user-oriented in that the 
using organization would decide how and when to use it, and for what pur- 
poses. 

4.3 IMPLEMENTATION 

The first step of implementation is a crucial one. We recommend that 
Center management appoint a policy team to draft and publish a Center 
policy concerning a center-wide IMS which provides a user-oriented service. 
An IMS planning team headed by the (new) Center Data Manager and composed 
of representatives of CAD, program offices, user organizations and several 
Data Management Systems engineering specialists, would then work out the 
system specifications, designs, and the size and extent of integrated data 
bases, and begin training within several months. We also recommend that 
the IMS planning team follow the phased-approach (to automation) recommenda 
tions presented in the following section. We believe the system could be 
in operation before the Space Shuttle Phase C/D contract is let. 
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5. AUTOMATED DATA MANAGEMENT TECHNIQUES 


The contribution of automation techniques to spacecraft operational 
data management system effectiveness was analyzed, and an approach believed 
to be cost-effective is recommended for future systems. This approach 
reflects consideration of the evolving nature of MSC's automation capabili- 
ties, the requirements for effective data management, and the characteris- 
tics of spacecraft operational data. The scope of this approach was ex- 
panded to consider the additional benefits derived from applying the 
approach to all the technical data of a program. Detailed discussions of 
these topics are presented in Section 3. of the Final Report, and are 
briefly discussed in the following paragraphs. 

While a manual data management system implemented to satisfy the re- 
quirements developed during this study would function, there are undersirable 
features to certain aspects of such a system - e.g., 1) the overriding 
emphasis on paper mechanics detracts from emphasis on data quality, 2) the 
time lags associated with paper processing and distribution, and 3) the 
complexities of search and update imposed on the user population. Converse- 
ly, there are many operations which must be performed manually, such as 
the definition and revision of data requirements, the establishment of 
validation procedures, and the follow-up on data availability. With the 
data itself, there are many items which are simply not good candidates for 
computer storage. Thus, during the next decade, any cost-effective system 
will undoubtedly be partly automated and partly manual. 

Automation alternatives were investigated to determine the extent to 
which the above considerations could be accommodated. It was assumed that 
present and planned automation capabilities of MSC would be available for 
use with operational data. At present there are two major computer com- 
plexes at MSC; the Univac 1106/1108 and the IBM-360. An information 
retrieval software system and an Exec VIII time share/terminal capability 
are expected to be operational on the 1106/1108 in the near future. A 
software system to effectively handle and edit large volumes of text materi- 
al is available. 
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The IBM- 360 complex has been traditionally committed to near real-time 
and real-time support of manned spaceflight missions. Relaxation from this 
status is evident from the recent implementation of the Mission Operations 
Planning System (MOPS) which provides an interactive mission planning 
capability further upstream in the mission development cycle than ever be- 
fore. Recent MSC sponsored studies by IBM and Computer Sciences Corpora- 
tion point to a sophisticated information management system in the future. 

It is anticipated that these complexes will eventually merge, either 
with software providing the interface or with a new set of integrating 
hardware. In addition, somewhere along this path an interactive graphics 
capability will be made available to the majority of the data user popu- 
lation. Automation of operational data would probably be constrained to 
start with the 1106/1108 information retrieval capability and a limited 
(in terms of the quantity of terminals available) time share/terminal capa- 
bility, and then increase in consonance with expansion of the automation 
capabilities of MSC. The flexibility to take advantage of these expanded 
capabilities should therefore be included in any plan for automation of 
operational data. 

The characteristics of operational data encompass the entire range 
of possible data characteristics in any technical area. Operational data 
include drawings, graphs, tabular data, and short and long text. The 
graphical, tabular, and short text data are the most dynamic in terms of 
update frequency, and the data management system would benefit most from 
the automation of these data types. Long text is usually descriptive in 
nature and does not require frequent change, while drawings are considered 
relatively invariant. 

In view of the progressively increasing automation capabilities 
anticipated and the broad spectrum of data characteristics comprising 
operational data, it appears that a cost-effective operational data manage- 
ment system would be achieved by: 
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1) Structuring the entire operational data population for indexing 
through a central source and automating a data reference file 
at the beginning of a program. This would serve to consolidate 
the identification, status, and location of data and would soon 
become recognized as the primary source for operational data. 

2) Structuring the more dynamic data (in terms of update frequency) 
into the automated data base. Key data users would be provided 
with terminal access (on a single "question and answer" basis) 
to that data which changes frequently. Data validators would 
have coded access for validation purposes. This would alleviate 
the search and update complexity encountered with large amounts 

of frequently changing paper. Graphical data which are not easily 
automated for widespread use at present, would be present in 
tabular format during the near-term. The user would have to plot 
his own graphs or have them plotted by use of his own batch or 
on-line plot program. Either of these alternatives is easily 
accomplished and is not considered a severe system constraint. 

3) Structuring the remainder of the data into a manual or semi- 
automated set of files indexed to conform with the data reference 
file described above. This would complete the integrated data 
base set. 

4) Providing a capability to maintain the entire integrated data 
base set and to handle new data requirements. At any point in 
time, the advisability of automating additional data would be 
assessed in terms of the available automation capabilities and 
experience with the automated part of the system. As both capa- 
bilities and experience increase, more and more data would be 
automated. Thus the undesirable features of a manual system de- 
scribed in previous paragraphs would be progressively eliminated. 

5) Publishing operational data to satisfy the large number of users 
who would not have convenient access to terminals and who do not 
require short update response times. Data contained in the auto- 
mated data base could be processed by direct computer printout 
and greatly alleviate the manual processing load. 

6) Prioritizing assignment of the limited quantity of teletype ter- 
minals presently available, reflecting the needs of both opera- 
rional data users for a given program and the needs of other 
terminal users for other programs. These priority decisions 
would undoubtedly be made by center-level management. 

The advantages of this phased approach to automation at the beginning 
of a program contrast favorably with the alternative of planning only for 
a manual system and then proceeding to automation when the need becomes 
critical. They include: 
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1) The long exposure period necessary for widespread acceptance of 
any system would commence upon implementation of management policy, 
thus facilitating earlier operational effectivity. 

2) The costly and confusing impact of changing some of the operations 
and roles of the data management system participants downstream 

in the program would be avoided (e.g., contract changes). 

3) The probable need to restructure manual data files to accommodate 
automation would be avoided. If the structuring of data files 
for automation is delayed, then when it does occur, the program 
impact will include start-up delays and widespread confusion about 
which data are available, and what data are valid. 

While the above approach is deemed cost-effective when applied to 
spacecraft operational data alone, it would be more cost-effective from an 
overall program standpoint if the data spectrum were expanded to include 
consideration of all technical data of the program. 

Operational data are extracted from gross estimates, technical require- 
ments and initial versions of end item specifications during the early seg- 
ment of a spacecraft program. As detailed analyses, performance models and 
development tests begin to occur, operational data are then progressively 
updated to reflect later knowledge, and finally during the operational phase 
of a program, these data are updated to reflect operational experience. 

Thus while operational data have not been the major product of any function 
during any phase of the program, they have been a minor product of a major- 
ity of the functions throughout the definition, design, development and 
operational phases. In essence, a portion of the data generated by these 
functions during each of these phases is operational data. 

Since spacecraft operational data are so interwoven with much of the 
technical data of a program, the above arguments in favor of phased and 
planned-from-the-beginning automation also appear to be applicable to 
automation of all technical data. In addition, consideration of all 
technical data would enhance retention of the close coupling between opera- 
tional data and the other technical data of a program reflected in the 
requirements of Section 3. 
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Additional benefits would be realized. Traditionally , program offices 
are responsible for maintaining a reasonable balance between program costs, 
schedules, and performance, and must detect and be responsive to unbalancing 
forces; this responsiblity is shared to varying extents with functional 
management. Information necessary to perform this function is derived in 
part from technical data in a manner similar to operational data. Auto- 
mation of all technical data (initially through development of reference 
files) would facilitate the correlation and extraction of the data necessary 
to provide management visibility. 

The above described benefits of automation appear to be of overwhelm- 
ing value to both the data management and program management efforts of 
future programs. For this reason it is recommended that the phased approach 
recommended above for operational data be widened in scope and applied to 
the development of an overall program information management system. 
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6. DEVELOPMENT OF OPERATIONAL DATA REQUIREMENTS 


Ideally all data requirements for a program would be known at the 
beginning of the program and would be specified explicitly in the initial 
contract. To a considerable and probably acceptable degree, this can be 
done for most spacecraft data since requirements, data management pro- 
cesses, and program management methods have matured from experience. How- 
ever, this does not appear to be the case for spacecraft operational data 
and shows up in the form of "time paradoxes" mentioned in Section 4. 
Examples are: the operational data user invariably recognizes additional 

data requirements at the conclusion of the development process, while the 
opportunity to satisfy these requirements occurs earlier in the development 
process; the mission planner's data requirements depend on hardware con- 
figurations, yet he is asked to supply definitive inputs to assist in 
selection of those same hardware configurations; even in preparing con- 
tracts, the operational data user is asked years in advance to define his 
requirements for data about systems not yet conceived. Possibly the most 
serious consequence of these paradoxes comes from those instances where 
data are irretrievably lost because an obvious need does not develop until 
after the acquisition opportunity has passed. We believe the solution to 
this problem is the system engineering function which relates hardware 
development to eventual operational employment. 

The operational data user must be represented in the hardware develop- 
ment process to resolve the paradoxes above, but his data problem is only 
a part of this system engineering function. The total job requires con- 
tinual interplay between the operations world and the hardware develop- 
ment world to produce an effective spacecraft system - i.e., continual 
iteration between operations analysis and hardware design. By maintaining 
an awareness of the operational data users' needs and expanding and refin- 
ing their stated requirements, the user can be supplied with the "best" 
available data and planning can be maintained to improve the data as future 
development and test activities permit. At any given time, a user's need 
in the far future will be specified now for acquisition and storage in the 
intermediate future . The user's representative in this process must 
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function from a base of experience acquired on a previous program and have 
sufficient training and maturity to exercise good engineering and program 
management judgement. The above system engineering activity suggests an 
Operations Analysis Group which might work along the lines of the Apollo 
Data Priority Group, but which would start at the beginning of the program. 
Further exploration of this subject is beyond the objectives of this study. 

Several recommendations are made for alleviating the operational data 
problem along a line compatible with the above. First, where requirements 
are known, they should be included in the prime contract RFP through DRL's 
and DRD's in conformance with current contracting practice. Second, those 
DRL's and DRD's should be coordinated on a program-wide basis to allow 
integration of requirements for operational data. Third, to assist in 
developing data requirements before contracts are firmed up, a technique 
such as that illustrated in Figure 3 is suggested. 

This technique causes the time-phased functional activities to be re- 
lated to their necessary input and output data needs. In the diagram, the 
black dots identify the activities for which the data items serve as input. 
That part of the diagram below the "MSC Data Base" would be largely a MSC 
activity while the upper part would be primarily a contractor responsibility. 
An example of both sections of the diagram would be included with the RFP. 

As a part of his proposal, the contractor would be expected to respond 
with a version reflecting his spacecraft development plan. This version, 
when negotiated, would be included by the NASA program office in an overall 
program data function diagram. Although complex and highly interrelated, 
the diagram would form the basis for the entire program data plan and 
structure of an automated data base. While difficult to maintain manually, 
elements of the diagram could easily be handled by an automated IMS with 
correlative features. As a result of this exercise in the RFP/Proposal 
stage, additional firm data requirements could be included in the contract. 

The common desire among operational data users for early and continual 
"best data" inputs deserves specific attention, since it affects the data 
management system discipline and apparent integrity. Operational data 
sources are reluctant to "formally" supply estimates which have limited 
"provability." Contractor management inhibits the submission of estimated 
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data which may later prove contradictory to the data eventually produced 
by the design, development, control and acceptance activities. The above 
conflicts are not completely resolved on the Apollo or Skylab programs. 

The following solution is recommended: 

1) The contract statement of work would provide for joint 
MSC/contractor estimates of expected spacecraft perfor- 
mance. It would limit contractor accountability to 
furnishing conscientious estimates by those contractor 
personnel best qualified to make such technical judge- 
ments, and specify that such estimates would have no 
contractual significance. 

2) The early data estimates, together with the basis for 
the estimates, would be placed in the automated data 
base of the IMS and keyed to trigger reassessment and 
reconfirmation of their validity at short-time intervals. 

This would serve to assure that an early estimate would 
not continue to drive program functions after it had 
become obsolete. 

To cover the unforeseen need for data after a contract is initiated, 
some Level of Effort (LOE) of a call contract nature should be included in 
the basic prime contract. The amount of the LOE needed might be estimated 
as some percentage of the effort spent on known data requirements. 
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